AWS ParallelCluster 3.1.1 のアップデート紹介

大村保貴

2022.02.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2022年2月11日に AWS ParallelCluster 3.1.1がリリースされました。3.0.0から5か月ぶりのマイナーアップデートです。

アップデート内容と、最新版のクラスターを作成しコンピュートノード起動までの動作確認を行いましたのでサンプルコンフィグともに紹介します。

アップデート情報

個人的な注目ポイントと、アップデートの目玉（っぽいもの）をピックアップしました。

アップデート詳細はリリースノートをご確認ください。

Release AWS ParallelCluster v3.1.1 · aws/aws-parallelcluster

Simple AD, AWS Managed Microsoft AD と統合し AD ベースのマルチユーザー認証をサポート
- 詳細は AWSS HPC ブログで紹介されています
インターネットアクセスができないサブネットでクラスター作成可能
pcluterコマンドの一部フラグに省略形の追加
- --cluster-nameが-nで省略可
キューごとに同じインスタンスタイプを持つ複数のコンピュートリソースをサポート
Arm ベースの GPU インスタンス（NVIDIA）をサポート
Ubuntu、CnetOS の起動時間が短縮
Amazon Linux2 起動時のパッケージの更新が無効になった

とくに気になったものは後ほど動作確認用のサンプルコンフィグで試してみました。

Arm ベースの GPU インスタンスについては以下の記事も参考にご覧ください。

サポートポリシー

v3.1代は v3.1.0のリリースはありませんでした。ということで v3.1.1が v3.1代一発目のリリースとなりました。

v3.1.1のリリース日（2022年2月11日）を起点に18か月先の2023年8月11日までサポートされます。

クラスター作成準備

以下のブログを参考にpclusterコマンドの最新バージョンをインストールします。

fish シェルユーザーなので.fishになっています。bashシェルユーザーは.bashに置き換えてください。

python3 -m venv pclusterVersion/311
source ~/pclusterVersion/311/bin/activate.fish
pip3 install aws-parallelcluster

pcluster version

現行最新版の3.1.1であることが確認できました。

{
  "version": "3.1.1"
}

ユーザーログイン後、自動的にアクティベートされるよう.bashrcの fish 版のコンフィグファイルにsource ~/pclusterVersion/[version]/bin/activate.fishを書き込みました。

vi ~/.config/fish/config.fish

最新版のクラスターを作成する環境は整いました。

IAMロール

pcluster create-clusterコマンドでクラスターを構築するために各種リソースを作成する権限が必要です。EC2インスタンスで ParallelCluster を管理している場合は IAMロールを見直しましょう。

以下のドキュメントに載っている IAMポリシーを IAMロールにアタッチしました。

Base user policy required to invoke AWS ParallelCluster features
Privileged IAM access mode
AWS Identity and Access Management roles in AWS ParallelCluster 3.x - AWS ParallelCluster

サンプルコンフィグ

一部アップデート内容の検証を兼ねて、以下の設定を加えてクラスターを作成し動作確認します。

マルチキューモード設定
- 同じインスタンスタイプ（c6g.large）を指定したキューを2つ作成
- スポットインスタンス起動指定
OS は Ubuntu を使用
- コンピュートノードの起動高速化に期待
プレイスメントグループ有効
セッションマネージャー接続できるようにIAMポリシー追加
postinstall処理未設定

Region: ap-northeast-1
Image:
  Os: ubuntu2004
HeadNode:
  InstanceType: t4g.micro
  Networking:
    ElasticIp: false
    SubnetId: subnet-035be95eeaa091603
  Ssh:
    KeyName: sandbox-key
  LocalStorage:
    RootVolume:
      Size: 50
      Encrypted: false
      VolumeType: gp3
      Iops: 3000
      Throughput: 125
#  CustomActions:
#    OnNodeConfigured:
#      Script: s3://blog-parallelcluster-postinstall/postinstall.sh
  Iam:
    S3Access:
      - BucketName: blog-parallelcluster-postinstall
        EnableWriteAccess: False
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: cpu-spot
      ComputeResources:
        - Name: queue1
          InstanceType: c6g.large
          MinCount: 0
          MaxCount: 5
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 35
            Encrypted: false
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      Networking:
         SubnetIds:
           - subnet-035be95eeaa091603
         PlacementGroup:
           Enabled: true
#      CustomActions:
#        OnNodeConfigured:
#          Script: s3://blog-parallelcluster-postinstall/postinstall.sh
      Iam:
        S3Access:
          - BucketName: blog-parallelcluster-postinstall
            KeyName: read_only/
            EnableWriteAccess: False
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    - Name: cpu-spot2
      ComputeResources:
        - Name: queue2
          InstanceType: c6g.large
          MinCount: 0
          MaxCount: 10
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 35
            Encrypted: false
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      Networking:
         SubnetIds:
           - subnet-035be95eeaa091603
         PlacementGroup:
           Enabled: true
#      CustomActions:
#        OnNodeConfigured:
#          Script: s3://blog-parallelcluster-postinstall/postinstall.sh
      Iam:
        S3Access:
          - BucketName: blog-parallelcluster-postinstall
            KeyName: read_only/
            EnableWriteAccess: False
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

クラスターを作成して動作確認

クラスター作成

クラスター作成コマンドを実行して10分ほど待ちます。今回のアップデートの省略形のフラグを早速利用してみました。

pcluster create-cluster -n sample-cluster311 -c sample-cluster311.yml

{
  "cluster": {
    "clusterName": "sample-cluster311",
    "cloudformationStackStatus": "CREATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/sample-cluster311/b4b8ed20-8b9c-11ec-90e5-06ad6e65260d",
    "region": "ap-northeast-1",
    "version": "3.1.1",
    "clusterStatus": "CREATE_IN_PROGRESS"
  }
}

クラスターが作成されたか確認します。CREATE_COMPLETEの表示を確認でき正常に構築が完了しました。

pcluster list-clusters

{
  "clusters": [
    {
      "clusterName": "sample-cluster311",
      "cloudformationStackStatus": "CREATE_COMPLETE",
      "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/sample-cluster311/aabfba10-8ba1-11ec-b32a-0a7891b89637",
      "region": "ap-northeast-1",
      "version": "3.1.1",
      "clusterStatus": "CREATE_COMPLETE"
    }
  ]
}

クラスターの動作確認

ヘッドノードにログインしました。同じインスタンスタイプを指定したパーティション名を確認できます。

$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
cpu-spot*    up   infinite      5  idle~ cpu-spot-dy-queue1-[1-5]
cpu-spot2    up   infinite     10  idle~ cpu-spot2-dy-queue2-[1-10]

-pフラグでパーティションを指定してすべてのパーティションにテストジョブを投入します。

$ sbatch -n 1 -p cpu-spot2 test.sh
$ sbatch -n 1 -p cpu-spot2 test.sh

キューに入りました。コンピュートノードが起動してくるのを待ちます。

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                 1  cpu-spot  test.sh   ubuntu CF       0:21      1 cpu-spot-dy-queue1-1
                 2 cpu-spot2  test.sh   ubuntu CF       0:08      1 cpu-spot2-dy-queue2-1

コンピュートノードが起動してきました。

コンピュートノードで処理されるとキューからジョブはなくります。

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

最新版のクラスターを構築しての簡単な動作確認は以上です。

Ubuntu の起動は本当に早かったの？

v3.1.1 で Ubuntu の起動速度に改善がみれたようなのでジョブを投入してから、Ubutun のコンピュートノードが起動してくるまでの時間を確認してみます。

ヘッドノードの/var/log/slurmctld.logログを確認します。

新しくジョブ（JobId=4）を投入時刻: 2:50:06
(この間にコンピュートノードが起動しています)
ジョブの処理を開始時刻: 2:52:41
ジョブが完了した時刻: 2:52:42

[2022-02-12T02:50:06.452] sched: Allocate JobId=4 NodeList=cpu-spot2-dy-queue2-1 #CPUs=1 Partition=cpu-spot2
[2022-02-12T02:52:31.566] Node cpu-spot2-dy-queue2-1 now responding
[2022-02-12T02:52:41.617] job_time_limit: Configuration for JobId=4 complete
[2022-02-12T02:52:41.617] Resetting JobId=4 start time for node power up
[2022-02-12T02:52:42.492] _job_complete: JobId=4 WEXITSTATUS 0
[2022-02-12T02:52:42.492] _job_complete: JobId=4 done

ジョブ投入からコンピュートノードが起動して処理開始するまでの時間は2分35秒でした。

ジョブはdateコマンドを実行するだけの内容でしたので1秒で終わることは間違いではないです。

感想

Postainstallでコンピュートノード起動時のセットアップ処理をしていないので早いのはわかるのですが想定よりも断然早いです。正確なデータを持っていなくて恐縮ですが、体感10分程度かかっていた印象があります。別の機会に古いバージョンのクラスターと条件揃えて起動時間計測してみようと思います。と個人的には興味深いデータが取れました。

後片付け

以下のコマンドでクラスターを削除できます。ここでもフラグの省略形が使えます。コマンドが短くなって助かります。

pcluster delete-cluster -n sample-cluster311

アップデートに関する動作確認結果

同じインスタンスタイプを指定したキューは問題なくコンピュートノードの起動に成功した
Ubuntu の起動時間短縮は本当に早いかもしれない
- 比較するための正確なデータを持っていないため体感レベルの感想
pclusterコマンドのフラグ--cluter-nameは頻出するため-nになるのはありがたい

おわりに

同じインスタンスタイプを指定したキューを複数作れなかったことにアップデート内容を確認するまで知りませんでした。他にも気になるアップデートがあり試したいのですが、速報レベルですべて検証する時間はなかったので別の機会に確かめたいと思います。

とくにインターネットアクセスできないサブネットでクラスター作成可能になったアップデートは、オンプレミスのプロキシ経由しないとインターネットアクセス不可の要件があったとき苦労したので当時の自分を救えるかもしれない。Arm ベースの GPU インスタンスとスポットインスタンスの組み合わせだと、コスト面でだいぶ攻めている構成なので活かせるアプリケーションがあれば面白そうですね。

気になって仕方がないのは Ubuntu の起動が本当に早いかもしれない点です。